Please review the following checklist.

• Docstrings on all new or modified functions / classes
• Updated documentation
• Updated CHANGELOG.md (where appropriate)

Hey 👋

I am combining realtime syncing provided by pycrdt with the TextArea widget and I am pretty impressed by how little code it takes to adapt the widget to my needs, given the complexity of src/textual/document/*.py and src/textual/widgets/_text_area.py.
Good job, @darrenburns!

Background Story

The edit flow in the released TextArea widget is:

TextArea.replace/insert/delete/clear  # <-- `maintain_selection_offset` set
  - TextArea.edit
    - Edit.do  # <-- `maintain_selection_offset` evaluated
      - TextArea.document.replace_range

with maintain_selection_offset deciding in Edit.do whether the current selection gets shifted/moved (True) or set as cursor to the end of the edit (False).

However, this edit flow is not compatible to CRDTs in pycrdt.
Changes to those CRDTs are announced via callbacks with event objects passed holding the information about a particular change.
For the Text-CRDT, there is the TextEvent event object holding info about which text range has been deleted and where a particular piece of text has been inserted.

This mechanism requires text manipulation on the TextArea widget - from the user via keyboard, the API or as update message from remote - to be done with the information given in the callback.
It does not provide a way of transporting arbitrary/app-specific metadata, especially not allowing to pass maintain_selection_offset flag:

TextArea.replace/insert/delete/clear
  - TextCRDT.insert/delete  # <-- `maintain_selection_offset` shall not pass
    - TextArea.on_ytext_event_callback
      - TextArea.edit
        - Edit.do
          - TextArea.document.replace_range

I thereby started experimenting whether I could get decent functionality without maintain_selection_offset.

What I Changed

• I removed maintain_selection_offset from the API.

• Edits via the API (insert, delete) do not automatically set the TextArea selection as a cursor to the end of the edit anymore (maintain_selection_offset = False before), but keep the current selection.
  See also tests for ctrl + u (delete to line start)

  comparison ctrl + u

  before:
  
  now:
  

  and ctrl + k (delete to line end).

  comparison ctrl + k

  before:
  
  now:
  

  On clear, maintain_selection_offset had no effect.

• Edits deleting a range covering the current TextArea selection place the selection as a cursor at the end of the edit.

  comparison

  before:
  

  now:
  

• Selection now supports the operators in, <, <=, > and >= for Locations (tuples).

• I updated the tests.

What are your thoughts, especially about the new API behavior?